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QoS SUPPORT IN CDMA2000 R-P NETWORK 
BACKGROUND OF THE INVENTION 

[0001] Without limiting the scope of the invention, its background is described in 
connection with network architectures that prioritize data according to type. 

[0002] The differentiated services (DiffServ) architecture described in RFC2475 is based 
on a simple model where traffic entering a network is classified and possibly conditioned (e.g., 
marked, metered, policed, shaped) at the boundaries of the network (i.e., at the edge router), 
and assigned to different behavior aggregates. Each behavior aggregate is identified by a 
single Differentiated Services Code Point (DSCP). Within the core of the network, packets are 
forwarded according to the per-hop behavior associated with the DSCP. Therefore, with the 
DiffServ architecture, the complexity is pushed into the edge of the network, while keeping the 
core routers simple. 

[0003] The edge routers in a DiffServ domain are also termed as ingress node or egress 
node, depending on the traffic direction. In a typical CDMA2000/3GPP2 network as shown in 
Figure 1, the Radio Node (RN), e.g. BTS is the ingress node for the uplink traffic, while the 
Packet Data Switching Node (PDSN) is the ingress node for the downlink traffic. In order to 
provide the DiffServ based QoS inside the R-P network (i.e., the IP network connecting RN and 
PDSN), the DiffServ functionality for the edge router, such as packet classification, marking, 
metering, policing and shaping should be implemented in RN and PDSN. In order to perform 
these functions, all the Qaulity of Service (QoS) related information needs to be properly 
relayed/configured into RN and PDSN. However, as described in section 2, the current 3GPP2 
specification doesn't fully support such functionality. 

[0004] In the current 3GPP2 standardization [3GPP2 P.S0001 C.4], flow mapping and 
treatment is originally introduced to map a particular downlink flow to a service instance. As 
described in 3GPP2 specification [3GPP2 P. S0001], in addition to a main service instance, a 
MN may open one or more auxiliary service instances to cany traffic that is not suitable for the 
main service instance. In order to effectively use the auxiliary service instance, the PDSN needs 
to be informed about the packet filters (i.e., the information used by the PDSN to classify which 
packet to be sent on which service instance). 

[0005] The mechanism to support DiffServ QoS in R-P network and external network 
has not been clearly defined in the current 3GPP2 standardization. The flow mapping 
mechanism described above can only be used to map a downlink traffic flow to a particular 
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auxiliary service instance, however, the mechanism for PDSN to obtain the OoS requirement of 
the flows inside an auxiliary service instance hasn't been defined. Although [TR45: 
Interoperability Specification (IOS) for cdma200 Access Network Interfaces - Part 2 Transport", 
PN-4545.2-RV3, Ballot Version October 2002] also stated that RAN policies or local policies 
defined by service provider can be used by RN and PDSN to mark and condition the uplink and 
downlink traffic, the mechanism for RN and PDSN to obtain the QoS requirement of the flows in 
order to apply the policy are not defined at all. 

[0006] As may be seen, an improved mechanism to improve functionality between two 
network nodes could provide an improved network architecture. 

FIELD OF THE INVENTION 

[0007] The present invention relates, in general, to prioritization of data between network 
nodes; and, in particular, to a method and system for establishing prioritization requirements 
between network nodes. 

BRIEF SUMMARY OF THE INVENTION 

[0008] The present invention presents an improved method and system for enabling 
traffic flow management between two nodes. 

[0009] This invention report proposes several approaches to provide DiffServ support to 
both uplink and downlink traffic over the R-P network and external network. In order for RN and 
PDSN to provide QoS and/or enforce QoS polices, they need to obtain the QoS requirement 
from the mobile node. This invention report to signal such QoS requirement at the link level 
using QoSJJLOB information or at the IP level via an extended dynamic flow mapping 
mechanism. This invention report also proposes how to use these QoS information at RN and 
PDSN to provide QoS support to the R-P network and external network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[00010] For a more complete understanding of the present invention, including its 
features and advantages, reference is made to the detailed description of the invention, taken in 
conjunction with the accompanying drawings of which: 

[0001 1] FIG. 1 DiffServ Domains in 3GPP2 Network System; 

[00012] FIG. 2 Flow Mapping and DiffServ Conditioning for Downlink Traffic: Solution 1 ; 

[00013] FIG. 3 Flow Mapping and DiffServ Conditioning for Downlink Traffic: Solution 2; 
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[00014] FIG. 4 Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 1 ; 
[00015] FIG. 5 Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 2; 
[00016] FIG. 6 Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 3; and 
[00017] FIG. 7 Integration of Solution2/uplink and Solution 2/downlink 
DETAILED DESCRIPTION OF THE INVENTION 

[0001 8] While the use and implementation of particular embodiments of the present 
invention are presented in detail below, it will be understood that the present invention provides 
many inventive concepts which can be embodied in a wide variety of contexts. The specific 
embodiments discussed herein are mere illustrations of specific ways for making and using the 
invention and are not intended to limit the scope of the invention. 

[00019] Appendix: Hereby incorporated by reference is an attached contribution by Nokia 
to a 3* Generation Project 2 "3GPP2 B standards body titled "Nokia Procedures for Supporting 
End-to-End QoS in the 3GPP2 System". 

[00020] A modified RSVP RESV message is used by the MS to signal one or more 
packet filters, called Traffic Flow Templates (TFT). The TFTs are only used to map downlink 
traffic to auxiliary service instance. The TFT IE, RESV message and protocol operation of 
dynamic flow mapping in downlink direction are described in [3GPP2 P. S0001] and will not be 
repeated in this document. The mechanism defined for flow mapping can be easily extended to 
provide QoS support to both uplink and downlink traffic over R-P bearer and external network. 
The QoS support defined here is DiffServ support and requires R-P network and external 
network to be DiffServ capable. Some approaches proposed in this invention report extend the 
service mapping mechanism to support DiffServ QoS in R-P and external networks. 

[00021] The QoS_BLOB defined in [TIA/IS-707-A-3] is used by the MN to signal the RN 
its QoS requirement for both uplink and downlink traffic. (Although QoS_BLOB is currently only 
defined in service option 33, it can be used for other type of service option as well.) Based on 
the QoS_BLOB, RN provides correspondent QoS over the air interface. However, no QoS 
support is defined for downlink traffic over the R-P connection. Although the downlink traffic 
coming into the PDSN from the external network could be marked with DSCP, PDSN may need 
to remark the packet based on downlink QoS requirement from the MN, user subscription policy 
(e.g., bandwidth limitation for a particular session) and other local network policy. In order for 
PDSN to mark the downlink traffic correctly based on its QoS requirements, besides the TFT of 
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the flow, the QoS requirements of the fiow need to be signaled to the PDSN as well. Two 
solutions are listed below. 

[00022] Solution 1 : RN sends downlink QoS information to PDSN - The basic idea of this 
approach is that RN obtains or derives the QoS requirement from the QoS_BLOB and then 
sends the QoS requirement to PDSN. This requires modification to the A1 1 interface to carry 
the QoS requirement of the downlink traffic. 

[00023] As shown in Figure 2, if MOB.QoS is set, the MN sends OM/EOM message with 
QoSjJLOB to the RN; otherwise, RN initiates the service negotiation or sen/ice option 
negotiation procedure, which carries the QoSJJLOB. Regardless of the procedure used, after 
obtaining the QoS_BLOB, RN sends the QoS information to the PDSN in an A11 message. 
Such A11 message could be a modified A1 1 RRQ message. (The modification to the existing 
interface and procedures in different network entities are shown in bold). The QoS information 
could be in the format of QoS__BLOB or RSVP FLOWSPEC or other QoS parameters. The 
PDSN obtains the downlink QoS requirement from the QoS information carried in A1 1 
message and then decides what DiffServ policies to be applied, based on local network policy 
and the user subscription profile. The DiffServ policies could include, but are not limited to, 
DSCP marking and traffic policing/shaping policies. The definition of these policies is subject to 
different service providers and is not within the scope of this document Only two examples of 
the DiffServ policies are given below. 

[00024] Examplel - DiffServ marking policy: The downlink traffic with QoS information 
with a requirement of requested bandwidth x bps, requested maximum delay y ms, and 
acceptable loss rate z%, will be marked with DSCP d1 . 

[00025] Example2 - traffic policing/shaping policy: The streaming application (specified 
by Traffic_Class or Application ID) used by a Gold user (high priority) should not exceed X bps 
during busy hour. Such policy could be specified in user QoS profile or defined by local network. 
Although the RN is aware of those policies, instead of possibly overloading R-P network, the 
PDSN can enforce the policies already to downlink traffic by dropping or shaping the out-of- 
profile traffic based on such a policy. 

[00026] After the DiffServ polices (e.g., DSCP used for the flows mapped to the service 
instance identified by the SR JD) are decided based on the QoS information for the service 
instance, they are mapped with the correspondent SRJD. The PDSN then responds to the RN 
with A1 1 message, such as A1 1 RRP message. In addition, in order for PDSN to map the 
downlink traffic into the correct service instance, the MN signals the TFT for the downlink traffic 
to the PDSN as defined in current CDMA2000 specification. When downlink traffic passes the 



-4- 



Express Mail No. 

Provisional Application for Haihong Zheng et al. 

NC37291 

PDSN, the PDSN first maps the packets into the correct service instance based on the TFT, and 
then marks the packet with the correct DSCP associated with the SRJD. Other possible 
DiffServ functions (e.g., policing, shaping) can be performed as well. 

[00027] Solution 2: MS sends downlink QoS requirement to PDSN 

[00028] The basic idea, as shown in Figure 3, is to signal the QoS requirements of the 
downlink traffic along with the TFT in the RESV message from the MN to the PDSN. The QoS 
requirement carried in the RESV message could still be the QoS_BLOB or a new information 
element or the FLOWSPEC defined for standard RSVP. After receiving the RESV message, 
the PDSN decides the DiffServ policy to be applied, based on the QoS requirement for the 
downlink traffic and creates the mapping between TFT, SRJD and DiffServ policy (as described 
for solution 1). 

[00029] The traffic handling procedure is the same as the ones defined in solution 1 . 
[00030] 5.2 Uplink Traffic 

[00031] In the current CDMA2000 specification, uplink QoS requirement can be carried in 
the QoS_BLOB and signaled between MN and RN. However, it is not specified how QoS is 
provided for the uplink traffic passing through the RN toward the PDSN and then to the external 
networks. In order to provide QoS support beyond the RN, the RN needs to be informed of the 
QoS requirements of the uplink traffic and it has to apply the correspondent DiffServ traffic 
handling policies. Three solutions are described below. 

[00032] Solutionl : Mapping from QoS_BLOB to DSCP - The basic idea of this approach 
is to directly map QoS_BLOB into DiffServ DSCP and other diffsev policies. As shown in Figure 
4, after obtaining QoS_BLOB for the service instance, based on the QoS requirement carried in 
the QoS_BLOB, the RN decides which DiffServ policies (DSCP marking) are to be applied to 
the service instance, then establishes the mapping between SRJD and DiffServ policy (e.g., 
DSCP). 

[00033] Solution 2: Mapping instructed by PDSN - The basic idea is to carry the QoS 
requirement for the uplink traffic in the RESV message, which is used to signal flow mapping in 
the current CDMA2000 specification. As shown in Figure 5, after receiving the uplink QoS 
requirement in the RESV message from MN, the PDSN decides which DiffServ policy (e.g., 
DSCP) is used for uplink traffic based on the QoS requirement. The QoS requirements sent in 
the RESV message could be in the QoS_BLOB format, or in the RSVP FLOWSPEC format, or 
a new information element standardized in 3GPP2 or other forum. After creating the mapping 
between SRJD and DiffServ policy, the PDSN not only configures it locally but also pushes the 
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uplink traffic handling policy into the RN. The protocol used by P.DSN to push the DiffServ 
policy for the uplink traffic could be COPS or modified A1 1 messages. Only COPS messages 
are illustrated in Figure 5. 

[00034] Solution 3: Mapping at RN via interception of RESV message - As shown in 
Figure 6, this approach is similar to Solution 2, where uplink QoS requirements are carried in 
the RESV messages. However, when the RESV message reaches the RN, the RN intercepts 
the message and extracts the SRJD and uplink QoS requirements, and then decides on the 
DiffServ policy and configures the policy locally. If the RESV message only carries the uplink 
QoS requirement, which is not needed for PDSN, RN can terminate the RESV message and 
sends the RESV_CONF message back to MN. Otherwise, RN forwards the RESV message 
toward the PDSN. The PDSN ignores the uplink QoS requirement information carried in the 
RESV message, and only processes the downlink part if exists. 

[00035] 5.3 Integrated Solution for Uplink and Downlink Traffic 

[00036] Although the solutions for uplink traffic and downlink traffic are documented 
separately, the correspondent solutions can be merged together. For example, when solution2 
for downlink traffic and solution 2 for uplink traffic are merged, the integrated solution is 
illustrated in Figure 7. Other combinations are also possible and are not illustrated in this 
document. 

[00037] While this invention has been described with reference to particular 
embodiments, this description is not intended to be limiting. Various modifications and 
combinations of the illustrative embodiments, as well as other embodiments of the invention, will 
be apparent to persons skilled in the art. It is, therefore, intended that the appended claims 
encompass any such modifications or embodiments. 
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ABSTRACT OF THE DISCLOSURE 

This invention report proposes several approaches to provide DiffServ support to both 
uplink and downlink traffic over the R-P network and external network. In order for RN and 
PDSN to provide QoS and/or enforce QoS policies, they need to obtain the QoS requirement 
from the mobile node. This invention report to signal such QoS requirement at the link level 
using QoS JJLOB information or at the IP level via an extended dynamic flow mapping 
mechanism. This invention report also proposes how to use these QoS information at RN and 
PDSN to provide Qos support to the R-P network and external network. 
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Figure 2. Flow Mapping and DiffServ Conditioning for Downlink Traffic: Solution 1 
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Figure 3. Flow Mapping and DiffServ Conditioning for Downlink Traffic: Solution 2 



QoS SUPPORT IN CDMA2000 R-P NETWORK 
Haihong Zheng el at. 
NC37291 



MN RN PDSN 



IF MOBJtoS a set, MN sends 
OM/EOM(SRJD, SO, QoS_BLOB); 
Otherwise, BS initiates service 
negotiation or server option procedure 
negotiation with Qo$_BLOB 



A11 RRQ(SRJD) 
A11 RRP 



Decide on diffserv policy for uplink 
traffic based on QoS_BLOB; 
Build mapping between 
(SRJD, diffserv policy) for uplink traffic 



4 SCM 



Figure 4. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 1 
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Figure 5. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 2 
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Figure 6. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 3 
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Figure 7. Integration of Solution2/uplink and Solution2/downlink 
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